Resource reservation methods in IP/Ethernet transport networks are increasingly important because carrier grade transport networks require methods for guaranteed services, i.e. services that provide a certain guaranteed quality of service (QoS). IP (Internet Protocol) transport is currently being introduced in mobile access networks, such as WCDMA RAN (Wideband Code Division Multiple Access Radio Access Network) and LTE (Long Term Evolution) networks. In such access networks user and signaling traffic often share limited transport resources. Therefore resource reservation of these transport resources is required. In order to provide dynamic resource reservation, signaling protocols are used.
There are several different methods for QoS control, such as IntServ (Integrated services) and DiffServ (Differentiated Services).
The idea of IntServ is to implement it in every router and every application that requires using transport resources in a router should make an individual reservation. The Internet Engineering Task Force (IETF) standardization organization has specified a signaling protocol called RSVP (Resource ReSerVation Protocol) for making transport resource reservation in IP routers. RSVP can be used to provide IntServ for real-time and non real-time traffic in the Internet. RSVP signaling messages reserve transport resources in each router along a data path before sending a real-time traffic flow. Real-time flows are admitted into the network if transport resources are successfully reserved in each router along the data path.
The IntServ method requires storing per-flow reservation states in each router along the data path. Storing and maintaining per-flow states in each router can be a problem in large networks, where the number of flows and therefore the number of reservation states is high. After recognizing this scalability problem of RSVP and IntServ, the IETF specified an RSVP aggregation method, which allows making reservations for aggregated flows. Aggregated reservation states are not necessarily created, modified or refreshed for each flow request.
The Diff Serv method for QoS control can be used to provide QoS in large-scale networks. In a DiffServ architecture scalability is achieved by offering services on an aggregate rather than per-flow basis and by forcing as much of the per-flow state as possible to the edges of the network. Service differentiation is achieved by using a Differentiated Services (DS) field in the header of IP packets. The IP packets are classified into Per-Hop Behavior (PHB) groups at DiffServ edge nodes. The applicable PHB of an IP-packet is indicated in the DS field of the IP header. The packets are handled in DiffServ routers according to the PHB indicated by the DS field. DiffServ is a scalable QoS method but it does not provide a QoS guaranteed service, therefore it requires higher bandwidths than signaling reservation methods such as IntServ.
The IETF Next Steps In Signaling (NSIS) Working Group is working on a protocol called NSIS (Next Steps in Signaling) to meet the new signaling requirements of today's IP networks, see RFC 3726 “Requirements for Signaling Protocols” by M. Brunner, published April 2004. The NSIS protocol consists of a transport layer and a QoS signaling application layer, which define a basic signaling mechanism. The QoS signaling application protocol of NSIS is called NSLP (NSIS signaling layer protocol). NSLP is fundamentally similar to RSVP but it has several new features, such as supporting different QoS Models.
One QoS model that can be implemented in NSIS is the IntServ model. Another QoS models under specification is Resource Management in Diffserv (RMD). RMD defines scalable admission control methods for Diffserv networks. It also includes a severe congestion function that is able to terminate the required number of packet flows in order to maintain the required QoS for the rest of the flows, in case of severe congestion situations, which may occur due to e.g. link or node failure. This congestion function is described in the international patent application WO2006/052174 A1, published on May 18, 2006.
The above described methods for QoS control relate to control of the use of transport resources. These methods are useful when transport resources are the scarce resources that limit the QoS that can be provided. However in case of other QoS limiting factors than transport resources, the prior art methods fail to provide adequate QoS control.